home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000474_guido@cwi.nl _Thu Dec 10 10:42:02 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <guido@cwi.nl>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA02898; Thu, 10 Dec 92 10:42:02 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA03135; Thu, 10 Dec 1992 10:55:27 +0100
  6. Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
  7.     id AA03712 (5.65b/3.2/CWI-Amsterdam); Thu, 10 Dec 1992 10:55:25 +0100
  8. Received: by voorn.cwi.nl with SMTP
  9.     id AA26659 (5.65b/3.2/CWI-Amsterdam); Thu, 10 Dec 1992 10:55:25 +0100
  10. Message-Id: <9212100955.AA26659.guido@voorn.cwi.nl>
  11. To: Dan Connolly <connolly@pixel.convex.com>
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: Gopher+ Considered Harmful 
  14. In-Reply-To: Your message of "Wed, 09 Dec 1992 21:15:36 MET."
  15.              <9212100315.AA14084@pixel.convex.com> 
  16. From: Guido.van.Rossum@cwi.nl
  17. X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
  18. X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
  19. Date: Thu, 10 Dec 1992 10:55:24 +0100
  20. Sender: Guido.van.Rossum@cwi.nl
  21.  
  22. I once explained the current HTTP protocol to a local network guru and
  23. he expressed concern that basing a protocol like this on TCP/IP is a
  24. great waste of network resources, since you are using a
  25. session-oriented protocol for what is essentially one remote procedure
  26. call.  My question "then what would you recommend instead" provoked no
  27. useful answer (what is needed is *reliable* datagrams, but these are
  28. not implemented as an IP protocol; UDP requires too much coding for
  29. time-out, retransmission and fragmentation).  Yet, he convinced me
  30. that a light-weight protocol like this should minimize the number of
  31. round-trips.
  32.  
  33. I have the feeling that the current trend of basing the new protocol
  34. on NNTP violates that requirement.  I like the idea of borrowing
  35. response and data formats from the FTP/SMTP/NNTP family of protocols,
  36. with suitable extensions for 8-bit data paths.  However I don't like
  37. it if compatibility with NNTP forces us to have an extra round trip
  38. just so that the server can give its welcome message.
  39.  
  40. Also, I don't like the fact that you must parse the RFC822/MIME header
  41. to find out how many bytes are to be expected.  This seems to be
  42. mixing two levels of protocols: MIME assumes that the end of the
  43. message is already known, and the MIME headers then tell you what to
  44. do with it.
  45.  
  46. As I see it, there are two possible ways of using MIME in HTTP+.  We
  47. can either support MIME as the *only* data format (implementing any
  48. extensions we need as new MIME content types or subtypes or additional
  49. headers), or we we support MIME as one of the possible data formats.
  50.  
  51. In both cases we need a way to indicate how much data follows; if all
  52. we ever send is MIME, all that is needed is a header indicating the
  53. byte count, otherwise a type identifier is needed as well.
  54.  
  55. --Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
  56. "The plumage don't enter into it.  He's stone dead!"